Computers operate under the control of a program consisting of coded instructions. Typically, programs are first written in a high level programming language, such as BASIC, PASCAL, C, C++, or the like, which are more readily understood by humans. The high level language statements of the source code are then translated or compiled into the coded instructions executable by the computer. Typically, a software program known as a compiler is used for this purpose. The terms, "source code" and "object code," are often used to describe the form of a program prior to and after compiling, respectively. Accordingly, the term "source code" generally refers to a program in its high level programming language form. "Object code," on the other hand, generally refers to the program in the form of the coded instructions generated by the compiler which are executable on a computer.
Typically, the source code of a programming language is organized in one or more program units, such as procedures, functions, blocks, modules, projects, packages and/or programs. These program units allow larger program tasks to be broken down into smaller units or groups of instructions. For example, in many programming languages, groups of instructions that are repeated frequently in a program can be organized into a single procedure or function. Each place in the source code where the group of instructions would otherwise be repeated, a reference (known as a procedure or function "call") to the procedure or function is instead used. Also, in some programming languages, related statements, procedures and functions are grouped together in program units, such as modules and the like. Some programming language systems are further organized in higher order program units, such as projects or the like, which may include one or more related lower order program units, e.g., modules. Considerable programming effort can be saved in subsequent programming work, by incorporating well-designed modules and projects from previous programs.
Programming effort also can be conserved through the use of a program unit known as a type library. Type libraries contain information defining the types of various program elements which may be incorporated within computer programs written in different programming languages. So that the information can be incorporated in programs written in different programming languages, the type information is made available through a standard procedural interface to application programs, including compilers, and interpreters. Type libraries and their use is described in U.S. patent application Ser. No. 07/959,056, entitled "Method and System for Interfacing to a Type Library," which is hereby incorporated by reference.
In source code, names (also known as identifiers) are generally explicitly assigned in declaration statements, to various program elements, such as variables, functions, procedures, and constants. (In some languages, names also may be assigned implicitly. For example, in FORTRAN, names beginning with i,j, . . . ,n are implicitly integer variables.) Typically, the declaration statements recite a name which is to be assigned to a program element , along with attributes of the program object (e.g. integer, string, array, etc . . . ). Other statements which operate on program elements, such as procedure calls, expressions, assignments, and the like, make reference to the program elements using their assigned names.
High level programming languages generally impose rules governing the scope of names (i.e. where a particular name is available in a program for referencing the associated program object). With statically scoped programming languages, names have a scope commensurate with the program unit in which they are declared. For example, names declared in a procedure generally are only available (i.e. in scope) within the procedure. Names declared in a module or project are generally available only within the module or project (and in its subunits). The names available within a particular program unit are generally referred to as the namespace of the unit.
As a part of the compiling process generally known as "binding" names to program elements, name references in the source code are matched to program elements currently in scope. Generally, to match a name to a program elements, previous compilers search the namespaces of the program units in which the name reference is located from a lowest order unit (e.g. a current procedure) to a highest order unit (e.g. a current project). If this search doesn't locate a program element with a matching name in these namespaces, the compiler generates an error.
In writing source code, it is sometimes desirable to make the names of program elements (hereafter "external program objects") declared within one program unit available for referencing within another program unit (hereafter "client program unit"). For example, it may be useful to include a function call within a client project which references an external function declared in another project. By making the external function available for reference within the client project, one can avoid having to declare the external function anew in the client project. Further, any subsequent changes to the external function can then be made to a single declaration of that function, thus avoiding possibly inconsistent multiple declarations of the function. Similar advantages attain for variables, constants, and other program elements.
In previous programming language systems, some mechanisms have been provided which permit access to external program elements. With some programming languages, such as Ada and Modula, the programmer writes an explicit export list in the source code for a program unit which contains the names of program elements which are to be made available for access within other, client program units. With some other programming languages, explicit import lists are used to identify external program elements which are to be made accessible within a client program unit. The Modula programming language, for example, employs both explicit export and import lists. As another example, the Ada programming language uses explicit import lists for separately compilable program units, and a declarations section which serves some of the same purposes as an export list. Such export or import lists generally take the form of a header file associated with the program unit or a statement within the program unit. The difficulty with these mechanisms is that they place an added burden on the programmer to maintain and update such lists as access to additional external program elements becomes necessary. The lists also add to the length and complexity of the source code, resulting in an increased opportunity for coding errors.
Additionally, in some programming language systems, access to external program elements within a client program unit is made with a "qualified" name reference. The name referencing a program element is qualified by adding or prefacing a name identifying the program unit in which it is declared. Typically the program unit name and program element name are separated by a "." or other delimiter. For example, an external program element named "PObj" which is declared in the program unit "PUnit" may be accessed with the qualified name, "PUnit.PObj." Where the source code is organized in several orders or levels of program units, the qualified name reference may comprise a string of program unit names. For example, a qualified name reference to access a function, "Func," declared in a module, "Mod," within a project, "Proj," may require the string of names, "Proj.Mod.Func." Again, this mechanism places an added burden on the programmer in that the program unit in which an external program element is declared must be explicitly recited in the source code each time the element is referenced. Accordingly, the programmer must mentally or otherwise keep track of numerous external program elements and the program units in which they are declared. With explicit qualification, the programmer also is required to recite a lengthier name reference to access external program elements, thus increasing the possibility of coding errors.
An object of the invention is to permit references to external program elements within a client program unit without resort to explicit qualification. Another object is to permit references to external program elements without explicit, programmer-written export or import lists of externally provided program elements. Yet another object of the invention is to enlarge the namespace of program units to include at least some external program elements of other program units. A further object of the invention is to provide access to external program elements of type libraries substantially equal to the access to external program elements of native program units.